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WITNESS SYSTEM 

Background of the Invention 
Field of the Invention 

5 The present invention relates to a Witness system 

that, using EDI (electronic data exchange), supports 
account settlement (accounting) and distribution 
systems among sellers and buyers. 

10 Description of the Related Art 

Today's distribution systems are manifold and, 
through complex distribution media, carry out the 
distribution of large quantities of goods. As a 
result, accounting processes undertaken between 

15 sellers and buyers are equally complex. 

The system disclosed in Fig. 1 is representative 
of conventional account settlement (accounting) 
systems. First, with each delivery of goods, a buyer 
examines a delivery voucher sent — or tendered 

20 contemporaneously on site — by a seller. Using, 
illustratively, an internal system in the buying 
company, the buyer then reduces the details to voucher 
form, upon which payment to the seller is to be based. 
This detailed voucher discloses, among other 

25 information, seller ' s name, delivery date, description 
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of goods delivered, unit price, quantity, and total 
price. 

The buyer thereafter consolidates and aggregates 
detailed vouchers according, illustratively, to 
5 payment date, and makes a detailed payment statement. 
The detailed payment statement so made is the result 
of the above-described consolidation and aggregation 
of each detailed voucher. Minute details otherwise 
recorded in a detailed voucher are omitted from the 

10 detailed payment statement. By way of illustration, 
payment date and total price are reflected in the 
detailed payment statement; more particularized 
details (e.g., delivery date, description of delivered 
items, unit price, and quantity), however, are 

15 commonly omitted. 

As between a buyer and seller trading daily many 
goods with a payment cycle of one payment per month, 
for example, detailed vouchers corresponding to 
delivered volumes are reduced to a single detailed 

20 payment statement, and only the aggregated total price 
is established according to the detailed payment 
statement . 

The buyer, using the above described detailed 
payment statement, requests that its bank transfer 
25 funds in favor of the seller. The bank then makes a 
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deposit for the amount specified in the detailed 
payment statement in favor of the Seller, with respect 
to whom the request for funds transfer was made, 
utilizing, illustratively, an inter-bank exchange 
5 system. As a result, a seller thus receiving payment 
learns, through notification from the bank, the amount 
of money received in the seller's bank account from 
the buyer. 

The following problems are inherent in a 

10 conventional system like that described above. 

Specifically, the detailed payment statement used in 
the conventional system is a document that compiles 
in the aforesaid manner multiple delivery vouchers in 
establishing a total payment amount. A seller is thus 

15 unable unilaterally to ascertain which delivery 
vouchers are reflected in the total amount paid to it 
by the buyer. This is the result of the omission of 
delivery date, description of delivered goods, unit 
price, quantity, and like information, for discrete 

20 transactions, from the detailed payment statement. 

In such instances, the seller must confirm 
substantive details with the buyer, in order to verify 
the amount of money received. Where, for example, the 
amount of money paid to the seller does not agree with 

25 the total amount invoiced, the seller's accounting 



representative must either confirm with the buyer the 
contents of the detailed vouchers or make discrete 
inquiries regarding payment amounts. This work places 
a significant burden on the accounting departments and 
5 constitutes a material impediment to enhancing the 
efficiency of account settlement processing. 

Specifically, where a single account settlement 
for a large transaction is undertaken according to the 
detailed payment statement, a great deal of time and 

10 human effort are required to confirm substantive 
details recorded therein. And, in settling accounts 
with high-volume customers, a seller must undertake 
account settlement in terms of the smallest 
transaction, i.e., by voucher, in order to set 

15 receivables off against payables. 

On the other hand, with the popularization of the 
internet, the construction of EDI -implemented 
(electronic data exchange) information exchange 
systems is being tested in all functional disciplines. 

20 It is anticipated that use of the system contemplated 
by the present invention will, particularly as between 
companies, facilitate more efficient account 
settlement processing and distribution in complex 
distribution channels. 



25 



5 

Summary of the Invention 

Utilizing EDI (electronic data exchange), the 
present invention provides a Witness system that 
ensures information safety, and further provides 
5 account settlement processes making use of said 
Witness system, in order to perform efficient account 
settlement processing and distribution. 

Specifically, the present invention achieves these 
objectives by providing a Witness system consisting 

10 of: Document making means for making confirmation 
documents based on records prepared by and sent from 
a seller for each seller record; forwarding means for 
forwarding to a notarization authority documentation 
made according to said confirmation document making 

15 means and, further, for forwarding said documentation 
from the aforementioned notarization authority to the 
aforementioned seller; confirmation means for 
confirming whether the content of the aforementioned 
documents forwarded by the aforementioned forwarding 

20 means agree with the content of the aforementioned 
seller records; a Witness for confirming that the 
aforesaid documents are correct, upon establishing the 
aforesaid substantive agreement according to said 
confirmation means; and memory means for storing in 

25 memory documents confirmed by said Witness. 



Records prepared by and sent from a seller 
include, by way of illustration, delivery vouchers, 
written estimates, invoices, and like records. These 
records are used to identify brand names, quantities, 
5 unit prices, and money amounts, when making details 
concerning goods received by a buyer. "Buyer" and 
"seller" comprise both public and private enterprises. 
The system contemplated by the present invention draws 
no distinction between incorporated and unincorporated 

10 entities. 

A notarization authority ( 1 ) receives details 
prepared by a seller based, among other things, on 
delivery vouchers, (2) transmits these details to the 
seller, and (3) solicits from the seller confirmation 

15 that substantive details are in agreement with the 
content of the delivery vouchers. The Witness 
receives notification that the seller confirms 
substantive agreement, whereupon the Witness certifies 
the aforesaid details as correct documents and 

20 confirms said details to the aforesaid buyer and 
seller. 

By constructing the system in this way, details 
for discrete deliveries prepared by a buyer are 
confirmed between buyer and seller, as well as by the 
25 third-party Witness. These details can be used 
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effectively as accurate data in account settlement 
processing. 

Brief Description of the Drawings 
5 Fig. 1 shows, illustratively, a conventional 

account settlement system. 

Fig. 2 discloses the specific structure of the 
system . 

Fig. 3 discloses the basic structure of the 
10 preferred embodiment of the Witness system. 

Fig. 4 discloses the structure that stores in 
memory media the programs for the illustrative 
embodiment . 

Fig. 5 discloses the order in which the computer 
15 performs processes J and K, and L and M, respectively. 
Fig. 6 shows the login screen. 

Fig. 7 shows a screen displaying the start menu. 
Fig. 8 discloses the menu bar details. 
Fig. 9 describes specifically the preferred 
20 embodiment . 

Fig. 10 presents flowchart describing the 
processes performed by computer 5. 

Fig. 11 presents flowchart describing the 
processes performed by the Witness PC. 
25 Fig. 12 presents a flowchart describing the 



processes performed by computer 6 . 

Fig. 13 shows the confirmation data list screen. 

Fig. 14 shows the data" confirmation screen. 

Fig. 15 shows the data confirmation screen. 

Fig. 16 shows the confirmed data list screen. 

Fig. 17 shows the confirmed data detail screen. 

Fig. 18 shows the payment list screen display. 

Fig,. 19 shows the payment display screen. 

Fig. 20 discloses a scaled representation of the 
comparison process. 

Fig. 21 describes represents the account 
settlement system in the case of funds transfer. 

Fig. 22 discloses the set-off process flow. 

Fig. 23 presents a flowchart describing the set- 
off process. 

Fig. 24 discloses the basic structure of the 
second alternate embodiment of the Witness system. 

Fig. 25 describes, with reference to a 
representative display screen, the processes for the 
second alternate embodiment. 

Fig. 26 describes, with reference to a 
representative display screen, the processes for the 
second alternate embodiment. 

Fig. 27 shows the login screen. 

Fig. 28 represents a screen displaying the start 



menu . 

Fig. 29 discloses the menu bar details. 
Fig. 30 shows the company certificate acquisition 
screen . 

Fig. 31 shows the confirmation number display 
screen . 

Fig. 32 shows the terms display screen, which 
displays the authentication authority terms. 

Fig. 33 shows the certification receipt screen. 

Fig. 34 shows the company registration screen. 

Fig. 35 shows the notarization authority terms 
screen . 

Fig. 36 shows the company registration request 
screen. 

Fig. 37 shows the company list screen. 
Fig. 38 shows the company detail information 
screen . 

Fig. 39 describes a Witness system utilizing a 
certificate. 

Fig. 40 describes specifically the second 
alternate embodiment. 

Fig. 41 describes the data format for encoded 
data. 

Fig. 42 discloses the notarization data list 
screen. 
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Fig. 43 discloses the notarization data 
confirmation screen. 

Fig. 44 discloses the notarization data 
confirmation screen. 
5 Fig. 45 discloses the notarized data list screen. 

Fig. 46 discloses the notarized data detail 
screen. 

Fig. 47 discloses the payment list screen display. 
Fig. 48 discloses the payment screen. 
10 Fig. 49 describes the account settlement system in 

the case of funds transfer. 

Fig. 50 discloses examples of other encoded data. 
Fig. 51 describes processing in the case of 
payment by check. 
15 Fig. 52 describes processing in the case of 

payment by draft ( note ) . 

Description of the Preferred Embodiment 

The preferred embodiments of the present invention 
20 are hereunder explained using accompanying figures. 

Fig. 2 discloses the basic structure of the 
Witness system's preferred embodiment. The 
illustrative Witness system consists, fundamentally, 
of: (1) a buying company, as "buyer"; (2) a selling 
25 company, as "seller"; and (3) the Witness, which 
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authenticates, as between buying company 1 and selling 
company 2, delivery vouchers and similar seller 
records. A buying company 1 purchases goods from a 
selling company 2. The buying company is, for 
5 example, a large supermarket or store, and the selling 
company is, for example, a vendor that delivers goods 
to large supermarkets and like purchasers. The goods 
delivered to the buying company consist, by way of 
illustration, of foodstuffs, articles of clothing, 
10 daily necessities, and all varieties of commercial 
goods . 

First, buying company 1 sends to the Witness 3 
data that buying company 1 wishes to have confirmed 
by the Witness 3. Exemplary data include that which 

15 is recorded on a delivery voucher (see Fig. 2(1)). 
Having received this data, the Witness first makes 
record only of the fact that it has received a 
request, and then sends the request, as is, to selling 
company 2 (see Fig. 2(2)). Having received the 

20 confirmation request, selling company 2 confirms the 
contents recorded in the aforementioned data and then 
executes, with respect to the Witness 3, a 
confirmation response indicating whether selling 
company 2 agrees with said data (see Fig. 2(3)). The 

25 Witness 3 receives the confirmation response and, if 



selling company 2 agrees with the recorded contents, 
transmits to buying company 1 and selling company 2 
a confirmation response representing that both parties 
have verified the aforementioned data (see Fig. 2(4)). 
5 The Witness 3 is thus possessed of faculties for 

undertaking simple recordation of the fact that it has 
received data from the buying company 1 and for 
proceeding further to confirm data (confirmation 
documents) exchanged between the buying and selling 

10 companies . The Witness 3 manages data and performs 
account settlement (accounting) processes relating, 
for example, to detailed payment statement making and 
funds transfers. 

Fig. 3 discloses the specific structure of this 

15 system. In this figure, diagram 5 represents the 
buying company's computer, and diagram 6 represents 
the selling company's computer (buying company 1 and 
selling company 2 are shown in Fig. 2). The Witness 
PC 9 corresponds to the aforesaid Witness 3. This 

20 Witness PC 9, among other things, confirms delivery 
voucher data output from the buying company's computer 
5, and receives confirmation responses output from the 
selling company's computer 6. 

The Witness server 8 comprises: Delivery detail 

25 table 20, which preserves in memory documentation 
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relating, by way of illustration, to delivery vouchers 
confirmed by monitoring system PC 9; payment terms 
table 21, which is described hereinafter; and detail 
group table 22. The above-mentioned computers 5 and 
5 6 can access directly the monitoring system 8 and can 
refer, illustratively, to the aforesaid confirmation 
documents . 

Additionally, as disclosed in Fig. 4, computer 5 
and computer 6 each perform processes described 

10 hereinafter according to programs (data) stored, for 
instance, in CPU RAM or on hard disk. The aforesaid 
programs may be supplied from either CD-ROM or floppy 
disk, or, alternatively, from a program (data) 
provider by means of a circuit. 

15 As disclosed in Fig. 3, the buying company's 

computer 5 executes requests for confirmation (process 
J) and executes administrative processing (process K) . 
The aforesaid processes are performed using database 
5a and library database 5b ( in computer 5 ) . Library 

20 interface 5 is used in this case. Similarly, the 
selling company's computer 6 executes data 
confirmation requests (process L) and administrative 
processing (process M). These processes are performed 
using database 6a (in computer 6) and library database 

25 6b, via library interface 6c. The dotted portions in 
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Fig. 3 represent a corporate client library, which 
functions, by way of illustration, as an interface for 
connecting to a network. 

The specification next describes processing in a 
5 Witness system constructed as described above. 

Fig. 5 discloses the order of processing when 
computer 5 executes processes J and K, or, 
alternatively, when computer 6 performs processes L 
and M. The display screen transition also is shown 

10 in Fig. 5. 

To begin processing for buying company 1, the user 
powers up computer 5, enters network user name and 
password, displays the icon corresponding to this 
system by, for example, clicking the [OK] indication 

15 on the screen, and double-clicks said icon to start 
the system. The same procedure is followed to start 
the selling company's computer 6, as well as the 
Witness PC 9 . 

The above-described process causes a login screen, 

20 as represented in Fig. 6, to appear on the display of 
computer 5 ( and on that of computer 6 ) . This login 
menu is used to start the Witness system disclosed in 
the illustrative embodiment and corresponds to the 
start screen in Fig. 5. 

25 By entering a user I.D. and network password and 
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activating the login button from this screen, computer 
5 (computer 6), for example, checks the user I.D. and 
password and, if they match, shifts to menu display 
to display the menu screen. If the cancel button is 
5 pressed, the display returns to the previous OS start 
screen. 

Fig. 7 shows the start menu displayed in response 
to manipulation- of the aforesaid login button. Said 
start screen consists of four buttons (display), 27a- 

10 27d, and a menu bar. As Fig. 8 discloses, the menu 
bar includes a quit bar. 

First, each button on the start menu is explained. 
Button 27a is used when directing the system to 
perform a confirmation request. Button 27b is used 

15 when directing the system to perform a payment list 
inquiry. Button 27c is used to direct the system to 
look at confirmed data. Button 27d is used to close 
the program described in the illustrative embodiment. 
Each button is activated, for example, by manipulating 

20 a mouse so as to position the cursor at any one of the 
buttons 27a-27d, and then double-clicking the mouse 
button. 

As disclosed above, among the processes that buyer 
company's computer 5 performs are processes J and K, 
25 and among those performed by selling company's 
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computer 6 are processes L and M. These processes are 
specifically explained below. 



Confirmation Request Process ( Process J ) : 
5 This process is performed by buying company 1 and 

is carried out based on either a delivery voucher, 
order voucher, or invoice, any of which serves as a 
seller record. Specifically, the buying company 1 
produces confirmation documents based on a voucher 

10 sent to it by selling company 2 and then sends the 
documents to the monitor. 

Fig. 9 specifically describes this process. Fig. 
10 presents a flowchart explaining the processes 
performed by computer 5. Each time buying company 1 

15 receives goods from selling company 2, the data 
contained in the delivery voucher that buying company 
1 receives is output from computer 5 to the Witness 
PC 9. 

As Fig. 9 illustrates, store A, the selling 
20 company 2, delivers to supermarket B, the buying 
company 1, certain foodstuffs and, at that time, sends 
to supermarket B a delivery voucher (or, 
alternatively, tenders the voucher with the goods ) . 
Computer 5 waits for input of the delivery voucher 
25 (step 1, hereinafter "SI", is N (no)), and, when the 
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delivery voucher is entered (SI is Y (yes)), the 
system performs input processing of the voucher 
information. As the example presented in Fig. 9 
shows, buyer company 1 (supermarket B) produces the 
5 aforesaid delivery voucher data as confirmation 
document XI. Included in this confirmation document 
XI are, illustratively, deliverer's name (selling 
company 1), delivery date, description of delivered 
goods, and delivered price. The following information 

10 is illustrative of that which is reflected in the 
confirmation document: The aforesaid deliverer is 
store A; the delivery date is February 10, 1998; the 
delivered goods consist of tuna; and the delivered 
price is 1,5000 yen. This confirmation document XI 

15 is transmitted (S3) from buyer company 1 to the 
Witness 3 (see Fig. 9(1)). Buying company's computer 
5 thereafter waits for a response with respect to the 
aforesaid transmitted data ( S4 ) . 

Fig. 12 presents a flowchart describing the 

20 processes performed by selling company's computer 6. 

The Witness PC 9 waits for the data input from the 
aforesaid computer 5 (S5 is N (no)), and, when the 
input is available (S5 is Y (yes)), confirms the 
content of the input data (S6) and, where, for 

25 example, the data supplied to the monitor PC 9 
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correspond to the above described confirmation 
document XI, said confirmation document XI is 
registered in detail table 20, described above (S7) 
(see Fig. 9(2)). Confirmation document XI is then 
5 output, as is, to selling company's' computer 6 (S8). 
Data Confirmation Process (Process K) 

Fig. 12 is a flowchart describing the process that 
selling company's computer 6 performs. As described 
above, computer 6 waits for the confirmation document 

10 XI input sent from the Witness PC 9 (S9 is N (no)), 
and, when confirmation document XI is input (S9 is Y 
(yes)), compares confirmation document XI with the 
contents of the delivery voucher that it previously 
sent (or tendered with delivery) (S10). It also 

15 checks to for the presence of errors in the contents 
of the delivery voucher. As noted above, it is 
selling company 2 that performs this error -checking 
task. A "buying company" with whom selling company 
2 places its goods is, however, not strictly limited 

20 to a specific company (the aforesaid buying company 
1). Accordingly, when undertaking the above-described 
error-checking task, selling company 2 presses the 
confirmation request button on the computer 6 start 
menu (see Fig. 7) and displays the confirmation data 

25 list screen shown in Fig. 13. 
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Fig. 13 is illustrative of the result following 
manipulation of retrieve button 40a, located on the 
confirmation data sight screen, and subsequent 
selection of "supermarket B" . To confirm this 
5 certification, selling company 2 presses detail button 
40b and displays the detail screen. Pressing the quit 
button 40c restores the above-described start menu. 

Here, the aforesaid detail button 40b is pressed, 
and the detail screen depicted in Fig. 14 appears. 

10 While looking at this screen, selling company 2 
compares the content of the confirmation document XI 
sent by the monitor 3 with the content of the delivery 
voucher, or similar document, issued by selling 
company 2 (S10). Selling company 2 then determines 

15 whether there are any errors (Sll). Here, if both 
documents are in substantive agreement, selling 
company 2 presses confirmation button 41a. The 
confirmation data is then produced and transmitted to 
the Witness PC 9 (Sll is Y (yes), S12, and S13 ) (see 

20 Fig. 9(4)). 

If, on the other hand, it is determined that the 
aforesaid delivery voucher, or similar document, and 
the confirmation document XI differ substantively (Sll 
is N (no)), selling company 2 presses NG button 41b, 

25 shown in Fig. 14, and produces the display disclosed 
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in the same figure. Specifically, selling company 2 
in this case describes the reason for the NG condition 
(S14), presses OK button 41, shown in Fig. 14, and 
sends .a NG response to the Witness PC 9 (S15). 
5 When this NG response is available (S5 in Fig. 11, 

is Y (yes)), the Witness PC 9 judges the contents of 
the input data (S6) and, in the case of a NG response, 
sends this information, as is, to buying company's 
computer 5 (S16). The Witness system thereafter waits 

10 for correction data input (S17). Buying company's 
computer 5 thus waits for the receipt of data (S4) 
and, in the case of a NG response when the response 
data is input (S18, see Fig. 10, is Y (yes)), 
undertakes correction corresponding to confirmation 

15 document XI (S19). The corrected data is sent a 
second time to the Witness PC 9 ( S20 ) , and receipt 
detail table 20 of the Witness PC 9 is corrected (S17 
is Y (yes), S21). Specifically, selling company 2 is 
able to: learn of an error or errors in the details 

20 generated by buying company 1 ; notify buying company 
1 of the error or errors; and (3) by, for example, 
correcting the content of the details, update the 
contents of receipt detail table 20, thereby enabling 
the of accurate details (see Fig. 9(5)). 

25 The process described above is performed each time 



a delivery voucher is sent between buying company 1 
and selling company 2, and several authentication 
documents are registered in the delivery receipt 
detail table 20 shown in Fig. 9. If, as represented 
5 in Fig. 9, the delivering company is store A, the 
delivery date is February 11 , 1998, the item delivered 
is saury, and the delivered price is 10,000 yen, a 
confirmation document X2, for example, is registered 
in the delivery detail table 20 according to the same 

10 process. 

Where selling company 2 determines that there are 
no substantive errors as between its delivery voucher 
and the confirmation document XI, and selling company 
2 sends a confirmation response to the Witness PC 9, 

15 the Witness PC 9 confirms the content of the input 
delta (S5 and S6, shown in Fig. 11), and the Witness 
PC 9 notifies buying company 1 and selling company 2 
that the data has been confirmed by both parties (S22) 
Specifically, when the Witness 3 has a "confirmation 

20 completed" input from selling company 2, it transmits 
to buying company 1 and selling company 2 
verification-completed confirmation documents A and 
B, relating, for example, to the above-mentioned 
confirmation documents XI and X2 (see Fig. 9(6)). The 

25 information thus transmitted from the Witness 3 is 
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confirmed by both buying company 1 and selling company 
2 and serves to verify that; there is no substantive 
error in a confirmation document based, for example, 
on a delivery voucher. 
5 When the confirmation process is completed as 

described above, confirmation documents based on 
several delivery vouchers are registered in the 
receipt detail table 20. 

To refer in this state to data that have been 

10 confirmed and registered in the receipt detail table 
20, the user presses the confirmed data list button 
7c, thereby shifting the display from the start menu 
configuration to the confirmed data screen represented 
in Fig. 16. This confirmed data list screen enables 

15 the user to select, from among several customers, a 
customer with which the user has current transactions, 
such as, by way of illustration. "00 Foods Company", 
"XX Ham Company", or "ABC Company". The user can also 
specify and select items in classification areas, such 

20 as "wholesale", "set-off", "orders", "accounts 
receivable", "payment corrections", and "contracts". 
Pushing button 45a, moreover, displays the confirmed 
data detail screen, shown in Fig. 17. 

Fig. 17 discloses the detail screen that appears 

25 when, by way of illustration, "orders" is selected as 
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the aforesaid classification item. As is shown in 
that figure, detailed information relating to the 
selected classification item is displayed, and the 
user is able to review in detail such specific 
5 authentication information as item name, quantity 
"10", unit cost "100 yen", and total cost "1000 yen". 
Office Administration Processing (Processes L and M) 
The specification next explains office 
administration processing. Office administration 

10 processing (process L) includes payment corrections, 
payment detail display, and like varieties of 
administrative processing. The payment correction 
process involves the correction of price or 
description of goods, pursuant to an indication of 

15 discrepancy made by selling company 2. Price 
establishment processes comprise, illustratively, 
responsive processes that are performed by confirming 
a detailed payment statement made by the Witness 3, 
and processes for outputting detailed payment 

20 statements that buying company 1 itself has made. 
These processes are specifically explained below. 

Fig. 18 represents a payment list screen 
appearing, for example, on computer 5. This payment 
list screen can be displayed by pushing the payment 

25 list inquiry (reference) button 27b, thus bringing 
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about a transition from the start menu configuration 
shown in Fig. 7. This payment list screen is 
generated by the Witness 3. By selecting payor, one 
is able to select from among several possibilities a 
5 company with which the user has current transactions 
(e.g., "00 Foods Company", "XX Ham Company", or "ABC 
Company" ) . Similarly, a payee can be specified, and, 
by specifying a date certain, a payment list screen 
showing that date as the due date is displayed. 

10 Displayed on this detailed list screen are the 

delivery date recorded on the payment voucher, voucher 
number, store name, wholesale price, and discount 
rate. An operator can specify another payment voucher 
about which information is desired, and, by pressing 

15 detail button 44a, can shift to the detail screen 
shown in Fig. 19. 

The illustration in Fig. 19 represents a payment 
voucher issued against "00 Foods Company", pursuant 
to which payment to "ABC Company" is due no later than 

20 August 12, 1997. When an operator at either buying 
company 1 or selling company 2 displays this 
information, the system investigates the product name, 
unit weight, quantity, unit price, and total price, 
and, in case of doubt, checks each detail registered 

25 in the above-mentioned receipt detail table 20. If, 
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for example, the total amount is different from the 
total amount based on the delivery voucher in the 
operator's possession, each detail registered in the 
receipt detail table 20 is confirmed. 
5 In this case, the system would refer to registered 

confirmation data residing in the receipts detail 
table 20. Specifically, by pushing the confirmed data 
button 7c from the start menu shown in Fig. 7, the 
aforesaid list screen, shown in Fig. 16, is displayed. 

10 It is also possible to cross-check payment data by 
displaying the confirmed data detail screen. 

Making of the detailed payment statement is 
undertaken, for example, by the Witness 3, and 
completed by referring to the payment terms table 21. 

15 According to prior arrangement between buying company 
1 and the Witness 3, or between selling company 2 and 
the Witness 3, information such as closing date, 
payment date, and deposit account number are for each 
company registered in the payment terms table. 

20 Additionally, each detail is numbered, and, to make 
data checking more convenient for buying company 1 and 
selling company 2, a detail group table 22, which 
groups the detail numbers, is provided. 

Fig. 20 presents a scaled drawing of the cross- 

25 checking process described above. Selling company 2 



26 

performs cross-checking of detailed information with 
the Witness 3 (see Fig. 20(1)) and, referring to 
either the receipts detail table 20 or the payment 
terms table 21, obtains the necessary detailed 
5 information (see Fig. 20(2)). On the other hand, 
buying company 1, also, performs cross-checking of 
detailed information with the Witness 3 (see Fig. 20 
(3)), as required, and, referring to either the 
receipts detail table 20 or the payment terms table 
10 21, obtains the necessary detailed information (see 
Fig. 20(4)). 

Next, the Witness 3 specifies the deposit account 
of the accounting department (i.e., a designated bank) 
and makes a request for deposit, based on the 

15 aforesaid detailed payment statement (see Fig. 9(7)). 
Here, using Fig. 21, the specification explains the 
deposit and cross-checking processes. 

Documents authenticated in the above-described 
manner are registered in the Witness server 8. First, 

20 the Witness 3 makes the detailed payment statement 
based on data registered in the receipts detail table 
20 and then requests confirmation from buying company 
1 (see Fig. 21(1)). Buying company 1 confirms the 
detailed payment statement sent to it and returns the 

25 statement as its request for funds transfer (see Fig. 
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21(2)). At this time, a delivery voucher index 
corresponding to the detailed payment statement is 
assigned to said statement. 

The aforesaid funds transfer request is delivered 
5 to the Witness 3 and forwarded to a bank (not shown 
in the instant drawing) (see Fig. 21 (3)). The 
information that the Witness 3 sends to the bank as 
the Witness' instruction for funds transfer comprises 
the money amount, transferor, transferee, and the 

10 detail index. Having been so instructed to transfer 
funds, the bank transfers funds to selling company's 
transaction bank, utilizing a suitable banking system, 
such as an inter-bank transfer system. The paying 
bank notifies selling company 2 of payment (see Fig. 

15 21(4)). 

By undertaking processing as described above, 
neither buying company 1 nor selling company 2 is 
required to hold several vouchers or invoices. 
Additionally, it is possible to perform efficient 

20 account settlement using data shared with the Witness 
server 9, 

First Alternate Embodiment: 

The specification next describes the first 
alternate embodiment of the present invention. If 
25 buying company 1 and selling company 2 were to change 
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places, processing efficiency would be impaired if 
respective detailed payment statements were made in 
the same manner as that contemplated in the preferred 
embodiment. This illustrative embodiment performs 
5 set-off processing and makes a detailed payment 
statement (suitable to the aforesaid contingency). 

Accordingly, the system structure disclosed in 
Figs. 2 through 4, as well as the illustrative screen 
progression shown in Fig. 5, are the same as those in 

10 the preferred embodiment. The making of confirmation 
document X based on delivery vouchers from selling 
company 2 is the same as that undertaken in the 
preferred embodiment. The confirmation process at 
selling company 2, as well as the authentication 

15 processes performed by the Witness 3 are the same. 

A plurality of authenticated data are registered in 
the detail receipts table 20 of the Witness server 8, 
and the Witness 3 makes detailed payment statements 
matched to payment dates in the payment terms table 

20 21. 

Fig. 22 discloses the set-off process flow for the 
illustrative embodiment. Fig. 23 is a set-off process 
flowchart. The illustrative embodiment performs set- 
off where, according to the relationship between the 
25 aforesaid buying company 1 and selling company 2, 
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buying company 1 bears a payment obligation with 
respect to selling company 2, and, at the same time, 
selling company 2 bears a payment obligation because, 
for example, it has purchased distinct goods from 
5 buying company 1. In this case, the system extracts 
all details relevant to buying company 1 and buying 
company 2 registered in delivery detail table 20 
"vendor" and "buyer" columns (Step 1, hereinafter "ST" 
in Fig. 23). Respective payment amounts are displayed 

10 (ST2), the money amount where buying company 1 is the 
buyer and selling company 2 is the vendor is added 
( + ) , the money amount where selling company 2 is the 
buyer and buying company 1 is the vendor is subtracted 
(-), and the set-off amount is calculated (ST3). 

15 The payment amount relating to mutual trade 

between buying company 1 and selling company 2 is thus 
sest-off according to the above calculation, and, in 
the preceding illustration, if the total money amount 
carries a positive (+) value, buying company 1 pays 

20 to selling company 2 the resultant money amount (ST4 
is Y (yes), ST 5 ) . If, on the other hand, the total 
money amount carries a negative (-) value, selling 
company 2 pays to buying company 1 the resultant total 
money amount ( ST4 is N (no), ST6 ) . 

25 The money amount thus derived is reduced to a 
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detailed payment statement, and, as described above, 
the Witness 3 specifies the accounting department 
(i.e., a designated bank) receiving account and 
executes a funds transfer request based on the 
5 aforesaid detailed payment statement (see Fig. 22 
(1)). By performing processing as described above, 
it is possible to reduce the number of detailed 
payment statements and to make detailed payment 
statements with greater efficiency. 

10 Set-off for payment amounts as between buying 

company 1 and selling company 2 is not limited to the 
foregoing illustrative embodiment, but is amenable to 
other methods as well . 
Second Alternate Embodiment 

15 The specification next describes the second 

alternate embodiment of the present invention. 

The second alternate embodiment is an invention 
for safely performing account settlement in an account 
settlement system utilizing the Witness. This 

20 illustrative embodiment performs processing in 
accordance with authentication numbers after 
authenticating buying company 1 and selling company 
2 in advance. Furthermore, the illustrative 

embodiment encodes data sent and received between 

25 buying company 1 and the Witness, or, alternatively, 
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between selling company 2 and the Witness, and ensures 
the protection of data. This illustrative embodiment 
is explained below. 

-Fig. 24 discloses the specific structure of this 
5 system. In this figure, 5 represents the computer of 
buying company 1, which is the same as that in the 
preceding illustrative embodiments, and 6 represents 
the computer of selling company 2. The notarization 
authority 7 and the Witness server 8 correspond to the 

10 aforesaid Witness 3 and are included in the Witness 
PC 9. The Witness PC 9 includes an authentication 
authority 24, which authenticates in advance the 
companies that participate in this system. 
Additionally, the Witness PC 9 in this illustrative 

15 embodiment notarizes (certifies) delivery voucher and 
like data output from buying company's computer 5, and 
also receives confirmation responses output from 
selling company's computer 6. 

The Witness server 8 consists, among other things, 

20 of: detailed receipts table 20, which stores 
notarization documents, illustratively comprising 
delivery receipts notarized by the Witness PC 9; 
payment terms table 21; and detailed group table 22. 
The aforesaid computer 5 and computer 6 can access 

25 directly the Witness server 8, to refer to the above- 
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mentioned notarization documents and like documents. 

As disclosed in Fig. 24, buying company's computer 
5 performs company certificate acquisition (process 
A), company registration processing (process B), 
5 notarization request processing (process C), and 
office administration processing (process D). Selling 
company's computer 6, on the other hand, performs 
company certificate acquisition (process E), company 
registration processing (process F), notarization data 

10 confirmation processing (process G) , and office 
administration processing (process H) . 

The authentication authority 24 executes 
authentication of certification requests issued in 
regard to the corporate certificate acquisition 

15 processes (viz., process A and E) undertaken by buying 
company's and selling company's computers (computer 
5 and computer 6, respectively). Similarly, the 
notarization authority 7 performs notarization of 
certificate issue registration requests issued in 

20 regard to company registration processing (viz., 
process B and F) carried out by buying company's and 
selling company's computers (computers 5 and 6, 
respectively) . 

Figs. 25 and 26 describe, in parallel with the 

25 representative screens that would appear on the 
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display, the processes of this illustrative 
embodiment. A specific explanation follows. 

In this illustrative embodiment, computers 5 and 
6 and the Witness PC 9 are powered up, and the Witness 
5 system program is started. 

Through this process, a login screen, represented 
in Fig. 27, appears on the computer 5 (or computer 6, 
for that matter) display. This login screen is used 
to open the monitor system in this illustrative 
10 embodiment and corresponds to the start screen in Fig. 
25. As with the previously described embodiments, 
entering a user I.D. and password and pressing the 
login button in the login screen causes computer 5, 
for example, to confirm the user I.D. and password. 
15 If the user I.D. and password are in agreement, the 
system transitions to menu display and brings up the 
menu screen. Pressing the cancel button returns the 
system to the previous, initial operating system 
screen . 

20 Fig. 28 represents the initial menu screen 

displayed when the login button is pressed. The 
initial menu comprises four buttons (display), 10a 
through lOd, and menu bar 11. Fig. 29 discloses 
details of the menu bar 11. Button 10a is pressed to 

25 instruct the system to confirm notarization requests. 
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Button 10b is pressed to instruct the system to 
retrieve a payment list. Button 10c is pressed to 
instruct the system to list notarized data. Button 
lOd is pressed to quit the program in this 
5 illustrative embodiment. 

As shown in Fig. 28, The menu bar 11 consists of 
quit bar 11a, company registration lib (company 
certificate acquisition bar lib' , company registration 
bar lib"), company information bar 11c, environment 
10 settings bar lid, and version information bar lie. 
The alphabetic characters (X, E, 1, S, A) assigned 
respectively to each of the bars are used when 
designations (specifications) are made via the 
keyboard . 

15 As described above, buying company's computer 5 

performs processes A through D, and selling company's 
computer 6 performs processes E through H. These 
processes are described specifically below. 

Company Certificate Acquisition Processes 

20 (processes A through E) 

These are processes for admission to the system 
and must be performed initially when, for example, 
this system is adopted. Designation of these 
processes is accomplished by selecting the company 

25 certificate acquisition bar in the menu screen shown 
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in Fig. 29 (Fig. 28) and displaying the company 
certificate acquisition screen shown in Fig. 30. As 
described above, the company certificate acquisition 
process (process A) is a process for registering 
5 companies participating in the Witness system in the 
illustrative embodiment and designating company 
registration numbers for companies whose company 
certificates are to be acquired, URL for the 
authentication authority, server name, and the type 

10 of certificate. 

Next, if there are no problems with respect to the 
entered company registration I.D., authentication 
authority's URL, or server name, the certificate 
request button 12a is pressed, producing the 

15 confirmation number display screen. When the quit 
button 12b is pressed, the display restores the 
initial menu shown in Fig. 28. 

Fig. 31 discloses the confirmation number display 
screen. After confirming the displayed number, the 

20 operator presses the "next" button 13a and displays 
the authentication authority terms. In this case, 
too, pressing the cancel button 13b restores the 
company certificate acquisition screen shown in Fig. 
30. 

25 Fig. 32 discloses the provisions display screen, 
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indicating the certification authority terms. Among 
these terms are, illustratively, regulations 
pertaining to admission to this system. The operator 
reads the terms and, if the operator agrees therewith, 
5 presses the consent button 14, or, conversely, if the 
operator is unable to agree, presses the cancel button 
14b. When the acceptance button 14a is pressed, the 
display shifts to the next certificate acquisition 
screen. 

10 Fig. 33 discloses the certificate acquisition 

screen. Company name, address, and other information 
relating to company in question are recorded in the 
corresponding areas therein, and the application 
request is made. After confirming that there are no 

15 mistakes in each of the entries, the application 
request is executed by pressing the application 
request button 15a. The aforesaid authentication 
authority registers the company pursuant to this 
request . 

20 Company Registration Processing (processes B and F) 
Company registration processing is performed after 
company certificate acquisition processing is 
completed as described above. 

Fig. 34 discloses the company registration screen, 
25 which can be displayed by pressing the company 



registration bar lib" in the start menu. This company 
registration process registers participating companies 
with the notarization authority 7 and designates the 
notarization authority 7 URL, server name, and the 
5 monitor I.D. (it is permissible, moreover, to 
abbreviate the server name and the monitor I.D.). 
This process also designates company registration I.D. 
for participating companies. 

Next, if there is no problem with, illustratively, 

10 the designated company registration I.D., the 
notarization authority 7 URL, and server name, 
registration number button 16a is pushed, producing 
the terms screen for the notarization authority 7 . 
Pressing the quit button 16b restores the start menu 

15 screen. 

Fig. 35 discloses the notarization authority terms 
screen. This screen, like that for the certification 
authority terms, presents, by way of illustration, 
regulations respecting admission to the system, 

20 confirmation items, and like entries. The operator 
read these terms and, if the operator agrees 
therewith, presses the consent button 17a, or 
conversely, if the operator is unable to agree, 
presses the cancel button 17b. When the consent 

25 button 17a is pressed, the display shifts to the next 
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company registration request screen. 

Fig. 36 discloses the company registration request 
screen, through which, company name, address, and 
other information relating to the company in question 
5 are recorded and the application request is executed. 
After confirming that there are no errors in each of 
the aforesaid entries, the request is executed by 
pressing the application request button 18a (the 
cancel button 18b is pressed to terminate the request 

10 process). 

The notarization authority 7 registers companies 
with the Witness server, pursuant to the above- 
described process. 
Company List Display 

15 Once each company has, as described above, 

executed registration with the notarization authority 
7 and the authentication authority 8, registration 
data for a plurality of companies are registered in 
the Witness server 9. Then, pursuant to user 

20 designations, the system is capable of displaying a 
list of registered companies. 

This company list is displayed by pressing the 
company information bar 11c from the start menu. Fig. 
37 discloses the registered company list display 

25 screen, on which is displayed registered company I.D., 
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company name, and registration date. In this 
illustration, company name "00 Foods Company" has been 
registered in area 1, company name "XX Ham Company" 
in. area 2, and "ABC Company-"in area 3. If there 
5 exists a company that a user wishes to examine in 
greater detail, the user specifies the company name 
and presses the detail button 19a, after displaying 
the above-described screen. 

Fig. 38 discloses the company detailed information 

10 screen that is displayed by pressing detail button 19 . 
This display consists of company I.D., company name, 
address, signature certification information, and 
encoding certificate information. If, for example, 
the company name "ABC Company" registered in area 3 

15 (se Fig. 28) is selected, the I.D. for "ABC Company" 
is registered in the company I.D. area, and the 
address for "ABC Company" is registered in the address 
area. Information to be registered with the "ABC 
Company" notarization authority is displayed in the 

20 signature certification information area, and the user 
can observe, for example, that certificate number 20 
was issued on November 9, 1997, and that a 
registration valid through May 10, 1998 has been 
executed . 

25 When the authentication process for companies 
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participating in the system (e.g., buying company 1 
and selling company 2) is completed, an encoding 
process is next performed. 

5 Notarization Request Process (Process C) 

This is a process performed by buying company 1 
and is carried out based on such seller records as a 
d€ilivery voucher, an order voucher, or an invoice. 
Specifically, it is a process wherein buying company 

10 1 makes notarization documents, based on any one of 
the vouchers sent to it by selling company 2, and 
seeks notarization from the Witness 3 . 

It is Fig. 39 that specifically describes this 
process. Fig. 39 is a scaled representation of the 

15 authentication process, which is executed by attaching 
the above-described certificate received by buying 
company 1 and selling company 2. Buying company 1 
appends to the authentication document the certificate 
[A] for buying company 1 and sends these documents to 

20 the Witness 3 (process (1) in Fig. 39). The Witness 
3 sends the authentication documents thus received, 
as is, to selling company 2 for confirmation (process 
(2) in Fig. 39). Selling company 2 checks the 
documents sent to it and, after confirming, 

25 illustratively, that the documents are in agreement 
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with the content of a delivery voucher, attaches its 
certificate [B] and sends the documents to the Witness 
3 (process (3) in Fig. 39). In addition to 
registering the authentication document data in the 
5 receipts detail table 20, the Witness 3 sends to both 
buying company 2 and selling company 1 notification 
that the Monitor has authenticated the authentication 
documents (process (3) in Fig. 39). This process is 
executed by appending the Witness' 3 certificate [C] . 

10 By thus appending the certificate to each document 
forwarded, the notarization authority 7 (Witness 3) 
is at once able to confirm at all times that the 
documents are those of companies eligible to 
peirticipate in the system and to execute safe 

15 procedures . 

Fig. 40 is used to advance a specific explanation. 
First, store A delivers foodstuffs to supermarket 
B, the buying company, and contemporaneously sends (or 
tenders on site) a delivery voucher. Selling company 

20 1 (supermarket B in this example) prepares data for 
use as a notarization document Y. Included in the 
notarization document Y are the deliverer's name 
(selling company 2 in this example), delivery date, 
description of delivered goods, and delivery price. 

25 Illustrative entries are as follows: deliverer's 
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name/ "store A"; delivery date/ "February 10, 1998"; 
description of delivered goods/"tuna" ; delivery 
price/"15, 000 yen". The notarization document Y is 
transmitted from buying company 1 to the Witness 3 
5 (see Fig. 40(1)). The notarization document Y sent 
fx'om buying company 1 to selling company 2 is first 
encoded . 

Fig. 41 is representative of this process. Here, 
a notarization document Y is sent from company U to 

10 company V. Adapting this scenario to the above 
illustration, the portion shown as "a" in the figure 
corresponds to a message relating to the sending of 
notarization document Y from buying company 1 to 
selling company 2. Specifically, DATA shown in Fig. 

15 41 corresponds, illustratively, to the deliverer's 
name and delivery date data, mentioned above. These 
data are encoded by means of DES, a hash function 
(SHA) is applied, further secured with buying 
company ' s secrecy key ( SKA ) , and sent to the 

20 notarization authority 7. A pubic access key (PKA) 
for the (SKA) is also sent with the data. The data 
are secured with buying company's secrecy key (SKA) 
to enable confirmation at selling company 2 that the 
message has been sent. 

25 The totality of transmission data sent from 



company U to company V is secured by locking with 
company U's secrecy key (SKU) a (message) to which a 
hash function (SHA) has been applied- This is further 
locked by DEK, which, in turn, is further secured by 
5 locking DEK corresponding to DES with company V's 
public access key (PVK). Locking with company V's 
public access key (PKV) ensures that the body of 
transmission data is susceptible of deciphering by 
company V only. Specifically, the body of 

10 transmission data is sent from buying company 1 to 
selling company 2. 

Notarized Data Confirmation Process (Process G) 

Next, the Witness 3 sends the aforesaid 
notarization document Y to selling company 2, the 

15 sender of the delivery voucher, and executes a 
confirmation request (see Fig. 40(3)). Selling 
company 2 compares the content of the notarization 
document Y transmitted from the Witness 3 with, 
illustratively, the content of a delivery voucher that 

20 selling company 2 itself issued, checking for errors. 

The above-described data is unlocked by means of the 
aforesaid public access key. 

Selling company 2, which has received the totality 
oif transmission data, first unlocks the data with the 

25 secrecy key (SKV) corresponding to the public access 
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key (PKA), obtains the DEK, unlocks the DES by means 
of the DEK, and then, as described above, utilizes 
buying company's public access key. 

The confirmation- task is, as above explained, 
5 performed by selling company 2. A buying company to 
which selling company 2 delivers goods is, however, 
not limited to the company prescribed above (buying 
company 1 ) . Accordingly, when performing the 
aforesaid confirmation task, selling company 2 presses 
10 the notarization request confirmation button 10a in 
the computer 6 start menu (see Fig. 28), thereby 
displaying the notarized data list screen, disclosed 
in Fig. 42. 

Fig. 42 illustrates a scenario wherein 
15 "supermarket B" is selected by manipulating the search 
button 20a on the notarized data list screen. To 
confirm this certificate, selling company 2 presses 
detail button 20b, thereby displaying a detail screen. 
When the detail button 20b is thus pressed and the 
20 detail screen displayed, the detail screen depicted 
in Fig. 42 appears. While observing this screen, 
selling company 2 confirms the content of the 
notarization document Yl, transmitted to it from the 
monitor 3, with the content of, illustratively, a 
25 delivery voucher that selling company 2 itself issued. 
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checking for errors. If the contents are in 
agreement, OK button 21a is pressed, and a completion 
(message) is transmitted to the Witness 3 (see Fig. 
40(4)). 

5 The confirmation response sent by selling company 

2 to the Witness 3 corresponds to that which is 
designated "b" in Fig. 41. Specifically, the encoded 
data for the aforesaid notarization document Yl is 
s€icured by means of a hash function (SHA) and selling 

10 company's secrecy key (SKB), and then sent to the 
notarization authority 7. A public access key (PKB) 
corresponding to the secrecy key is sent 
simultaneously to the notarization authority 7. 

If it is determined that the content of the 

15 notarization document Yl is not in accord with, 
illustratively, the content of a delivery voucher, 
confirmation NG button 21b shown in Fig. 43 is 
pressed, resulting in the display represented in the 
same figure. Specifically, the operator describes the 

20 reason the reason for NG and presses OK button 22a. 
In this case, the Witness 3 notarizes no details, and, 
at this point, Seller 2 learns that there is an error, 
or that there are errors, in the details prepared by 
Buyer 1. Seller 2 notifies Buyer 1, and, as the 

25 content of the details are revised, the receipts 
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detail table 20, for example, is updated, thereby- 
enabling Buyer 1 to produce accurate notarization 
details (see Fig. 40(5)). 

Once the Witness 3 has a confirmation response 
5 from selling company 2, it transmits to selling 
company 2 and buying company 2 a confirmed certificate 
relating to the notarization document Yl (see Fig. 
9(6)). 

The certificate that selling company 2 sends at 

10 this time to the Witness 3 corresponds to that which 
is designated as "c" in Fig. 41. Specifically, it is 
a message secured by means of (1) a hash function 
(SHA) applied to encoded data relating to notarization 
document Yl and ( 2 ) the monitor ' s 3 secrecy key ( SKN ) . 

15 An access key corresponding to said secrecy key (SKN) 
is at this time sent to both buying company 1 and 
selling company 2. 

Thus, decoded information sent from the Witness 3 
constitutes a certificate that has been confirmed 

20 mutually by buying company 1 and selling company 2, 
and further constitutes a notarization document 
certifying that there are no substantive errors in the 
authentication document based, illustratively, on a 
delivery voucher. As the notarization process is thus 

25 completed, a plurality of certificates are registered 
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in. the receipts detail table 20. 

System users can consult notarized, registered 
data residing in the receipts detail table 20 by 
pressing start menu (see Fig. 28) button 10c, which 
5 enables viewing of the notarized data list. The 
resulting notarized data list screen is disclosed in 
Fig. 45. The notarized data list screen allows the 
user, for example, to select "customer" and then 
specifically identify, illustratively, "00 Foods 

10 Company", "XX Ham Company", "ABC Company", or any 
buying company 1 with which the selling company 
currently has transactions. The user can also select 
matters that the user wishes to confirm by specifying 
items in the classification areas "wholesale", "set- 

15 off", "orders", "accounts receivable", "payment 
corrections", and "contracts". Pressing detail button 
25 displays the notarized data detail screen shown in 
Fig. 46. 

Fig. 46 represents the detail screen displayed 
20 when the classification item "orders" is selected. 

As shown in Fig. 46, detailed information for the 
selected item is displayed, facilitating review of 
specific authentication details including, 
illustratively, product name, quantity ("10 pieces" 
25 in this example), unit price ("100 yen" in this 
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example), and total price ("1000 yen" in this 
example ) . 

Office Administrations Processes (Processes D and 

H) 

5 Next, the specification describes the office 

administration processes. Among the office 

administration processes (process D) are payment 
correction, payment detail display, and various 
varieties of like processes. Payment correction 

10 facilitates correction, for example, to the price or 
description of goods appearing in the authentication 
document, pursuant to notification of error received 
from selling company 2. Price settlement includes, 
for example, a response process executed by confirming 

15 detailed payment statements prepared by the Witness 
3, and a process wherein detailed payment statements 
prepared by buying company 1 itself are output. These 
processes are explained specifically below. 

Fig. 47 discloses, by way of illustration, the 

20 payment list screen appearing on the computer 5 
display. This payment list screen is displayed by 
pressing the payment list inquiry button 10b in the 
start menu, shown in Fig. 30. The payment list screen 
is generated by the Witness 3, and, by selecting the 

25 payor, the user can select, for example, "00 Foods 
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Company", "XX Ham Company", "ABC company", or any 
payor with whom the user conducts business. Also, 
when a payee is in the same way designated and a date 
specified, that date is displayed as the payment date 
5 in the payment list. 

The delivery date relating to the payment voucher, 
voucher number, store name, wholesale price, and 
discount rate, are displayed on this detailed list 
screen. By specifying a payment voucher about which 

10 more information is desired and pressing detail button 
24a, the operator can shift to the detail screen 
represented in Fig. 48. 

Fig. 48 is an illustrative screen showing a 
payment voucher requiring payment from payor "00 Foods 

15 Company" to payee "XYZ Company" not later than August 
12, 1997. With this information displayed, the buying 
company 1 operator, or the selling company 2 operator, 
investigates product name, unit weight, quantity, unit 
price, total price, and like information, and, in case 

20 of any doubt, confirms each detail registered in the 
aforesaid receipts detail table 20. If, for example, 
the total amount differs from the amount determined 
based on the delivery receipt in the operator ' s 
possession, the operator checks each detail registered 

25 in the receipts detail table 20. 



In this case, the operator would review the 
notarized, registered data residing in the receipts 
detail table 20. Specifically, the operator displays 
the aforesaid list screen shown in Fig. 45, by pushing 
5 the notarized data list button 10c from the start menu 
shown in Fig. 28. Further, the operator can display 
the notarized data detail screen and review payment 
data. 

The detailed payment statement, which, by way of 

10 illustration, can be prepared by the Witness 3, is 
produced with reference to the payment terms table 21. 
Due date, payment date, receiving account, and like 
information are for each company registered in the 
payment terms table 21, by prior arrangement between 

15 buying company 1 and the Witness, or between selling 
company 2 and the Witness 3. Furthermore, each detail 
is assigned a detail number in the receipts detail 
table 20, and, for convenient review by either buying 
company 1 or selling company 2, a group table 22, 

20 grouping detail numbers, is prepared. 

Based on the aforesaid detailed payment statement, 
the Witness 3 next specifies the accounting department 
(i.e., a designated bank) receiving account and 
executes a funds transfer request (see Fig. 40(')). 

25 Fig. 50 describes the funds transfer process. 



The Witness 3 prepares the detailed payment 
statement based on the data registered in the receipts 
detail table 20 and requests confirmation from buying 
company 1 (see Fig. 49(1)). Buying company 1 confirms 
5 the detailed payment statement sent to it by the 
Witness 3 and returns said detailed payment statement 
as a funds transfer request (see Fig. 49(2)). At this 
time, a delivery voucher index corresponding to the 
detailed payment statement in question is assigned to 

10 Sciid detailed payment statement. 

The above-described funds transfer request is 
delivered to the Witness 3, via the notarization 
authority 7 (see Fig. 49 (3)), and transmitted to the 
bank, which is not represented in the instant figure. 

15 The funds transfer instruction sent by the Witness 3 
to the bank consists of the money amount, transferor, 
transferee, and the detail index. Having received the 
funds transfer instruction, the bank transfers funds 
to the appropriate account at selling company's 

20 transacting bank, utilizing a suitable banking system 
(e.g., the inter-bank exchange* system described 
above). The paying bank issues a payment notification 
to selling company 2 (see Fig. 49(4)). 

By performing processing as described above, 

25 buying company 1 and selling company 2 are not 
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required to hold several delivery vouchers and 
invoices and can execute efficient account settlement 
processing by sharing and using information provided 
by the Witness server 9 - 
5 Data transmitted ( sent and received ) among buying 

company 1, selling company 2, the notarization 
authority 7, and the Witness, are encoded and prepared 
as necessary to suit their respective transmission 
purposes. The illustrative data shown in Fig. 50 are 

10 prepared for the purpose of substantive disclosure by 
buying company 1 [A] to both selling company 2 [B] and 
the Witness [W] . In this case, the data have been 
locked (secured) in advance with the selling company's 
public access key ( PKB ) , which is held by buying 

15 company 1, and the Witness' public access key (PKW). 

The data are further secured with a hash function and 
buying company's secrecy key (SHA), and then sent with 
a public key (PKN) appended thereto. This structure 
makes it impossible to release the aforesaid data 

20 without both selling company's secrecy key and the 
Witness ' 2 secrecy key, and knowledge of the 
information is thus strictly limited to selling 
company 2 and the monitor 3 . 

Although the explanation of this illustrative 

25 embodiment does not touch upon the set-off process, 
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said process can be implemented as set forth in the 
description of the previous illustrative embodiment. 

Third Alternate Embodiment: 
5 This portion of the specification describes the 

third alternate embodiment. 

This illustrative embodiment is directed 
particularly to account settlement by means of check 
or draft ( note ) , and can be implemented through 

10 S3fstems based on both the above-described preferred 
and first alternate embodiments. Each contingency, 
viz., check and draft (note), is explained below. 

Fig. 51 describes, illustratively, account 
settlement in the case of checks. The administration 

15 center 50 shown in said figure comprises a 
notarization authority 51 and the Witness 52. The 
administration center adopts the Witness system 
described above and also undertakes management of 
bank-issued checks. Bank X represents the transacting 

20 bank for payor/buying company 1, and bank Y represents 
the transacting bank for receiver/selling company 2 . 

First, buying company 2 (payor) issues a check. 
In the illustrative case, buying company 3 (payor), 
wishing to issue a check in payment for goods, must 

25 obtain a check by requesting that its transacting bank 
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X issue a check (see Fig. 51(1)). Bank X examines the 
applicant's eligibility and, when it is determined 
that a check ought to issue, the bank registers with 
the administration center 50 the issuance of a check 
5 to buying company 1 (see Fig. 51(2) and simultaneously 
authorizes buying company 1 to issue a check (see Fig. 
51(3)). 

Having so obtained the check, buying company 1 
uses the check in payment for goods and tenders the 

10 check, on which are recorded the payee's name and the 
money amount, to selling company 2 (payee) (see Fig. 
51(4)). Selling company 2 takes the check it has 
received to the aforesaid transacting bank X and 
requests payment (see Fig. 51(5)). 

15 Transacting bank X inquires of the administration 

system regarding the check presented to it and, in 
addition to confirming its validity, registers said 
check as paid by means of a payment notification (see 
Fig. 51(6)). Transacting bank X thereafter utilizes 

20 an inter-bank system to move funds to the specified 
account at the designated transacting bank (bank Y in 
this illustration), and bank Y then dispatches to 
selling company 2 notification of collection (see Fig. 
51(7)). 

25 In this illustrative embodiment, the 
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administration center is composed of a notarization 
authority and a Witness (system). The system 
undertakes check administration in the above-described 
network. Selling company 2 is the entity requesting 
5 that funds be transferred to bank Y. 

Processing of Drafts (Notes) 

.This portion of the specification explains the 
embodiment in the case of drafts (notes). 

10 Fig. 52 describes, illustratively, account 

settlement for drafts ( notes ) . As in the check 
processing system, here, also, the administration 
center ( 53 ) is composed of a notarization authority 
54 and a Witness 55. The administration center adopts 

15 the above-described Witness system and also undertakes 
administration of bank-issued checks. Bank X 
represents the transacting bank for buying company 
1 /payor, and bank Y represents the transacting bank 
for selling company 2/payee. 

20 First, buying company 1 receives from transacting 

bank X authorization to issue a draft (note) (see Fig. 
52(1)). Next, buying company 2 registers issuance of 
a draft with the administration center 53, at the time 
buying company desires to issue said draft (see Fig. 

25 52(2)). The administration center 53 registers this 
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information and notifies buying company 1 of "the 
registration number (see Fig. 52(3)). 

Buying company 1 adds to the registration number 
it has received a draw date, a drawee (payor), and a 
5 drawer (payee), and sends this information to selling 
company 2 (drawer) (see Fig. 52 (4)). Selling company 
2 presents this draft (note) to its transacting bank, 
bank Y in this example, where it might request that 
bank Y purchase the draft (note) at a discount (see 

10 Fig. 52(5)). 

Bank Y confirms the information in said draft 
(note) with the administration center 53 and, further, 
registers with the administration center 53 the fact 
that bank Y itself is to be the drawer (payee) (see 

15 Fig. 52(6)). Also, bank Y pays a discounted amount 
to selling company 2 (see Fig. 52(7)). 

Lastly, as the (payment) date approaches and the 
draft (note) is converted into currency, a settlement 
demand is tendered to the issuing bank (see Fig. 

20 52(8)), and bank X, which receives the settlement 
demand, uses the aforesaid inter-bank exchange system 
to move funds to the account at bank Y. Bank Y then 
provides notification of completion to the 
administration center 53 (see Fig. 52(9)). 

25 The administration center 53 for processes 



executed in this illustrative embodiment comprises a 
notarization authority 54 and a Witness 55. The draft 
(note) administration flow for this illustrative 
embodiment, also, is performed as described above. 
5 The Witness system- can be used for this illustrative 
embodiment, as well. 

The following benefits are derived from the 
present invention. Through means of a single 
invention, the Witness stores (stores in memory/ holds 

10 in memory) and manages data relating, illustratively, 
to order vouchers and delivery vouchers, thus 
facilitating the preparation of accurate detailed 
payment statements. Additionally, because both Buyer 
and Seller can freely review detailed payment 

15 statements so prepared, it is not particularly 
necessary for Buyer or Seller to hold order vouchers 
and delivery vouchers. It is therefore unnecessary 
to perform the complicated task of arranging 
(organizing) various vouchers. 

20 In contrast to conventional settlement methods 

wherein Buyer prepares payment details while 
confirming order vouchers or delivery vouchers, it is 
no longer necessary for Seller to undertake the 
difficult task of confirming said payment details. 

25 Furthermore, system safety is ensured because 
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eligibility to participate in the system is verified, 
and because the exchange (transfer) of information is 
executed with encoded data. 
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What is claimed is: 

1. A witness system, comprising 

confirmation document making means for making 
5 confirmation documents for each buyer record, based 
on a seller record, or records, sent from a seller, 

sending means for sending to the witness documents 
prepared according to said confirmation document 
making means, and for sending said documents from said 
10 witness to said seller, 

confirmation means for confirmation by said seller 
that the content of said seller record, or records, 
is in agreement with the content of said documents 
sent according to said sending means, 
15 a witness to confirm that said documents are 

accurate, when said agreement is confirmed according 
to said confirmation means, and 

memory means for storing in memory documents 
confirmed by said witness. 

20 

2. A witness system according to claim 1, wherein 
a buyer makes said confirmation documents . 

3. A witness system according to claim 1, wherein 
25 when said witness confirms the confirmation 



60 

documents, said witness notifies both the buyer and 
seller of the confirmation. 



4. A witness system according to claim 1, wherein 
5 when said confirmation documents are sent from 

said seller to said witness, said documents are 
registered, and the fact that said documents are 
registered is confirmed. 



10 5 A witness system according to claim 1, wherein 

when said contents do not agree, as determined 
according to said confirmation means, said witness is 
notified of the substantive disagreement. 



15 6. A witness system according to claim 1, wherein 

the storing in memory of said documents according 
to said memory means is undertaken with respect to 
each buyer and each seller. 



20 7. An account settlement system, comprising 

notarization document making means for making 
notarization documents for said each buyer record, 
based on seller records sent from said buyer, 

sending means for sending to a notarization 
25 authority documents made according to said 
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notarization document making means, and for sending 
said documents from said notarization authority to 
said seller, 

confirmation means by which said seller confirms 
5 whether the contents of said seller records are in 
agreement with the contents of records sent according 
to said sending means, 

a witness that includes a notarization authority 
that certifies the fact that said documents are 
10 accurate, when said substantive agreement is confirmed 
according to said confirmation means 

memory means for storing in memory documents 
notarized by said witness, 

detailed payment statement making means for 
15 making, with reference to said notarization documents 
stored in memory according to said memory means, a 
detailed payment statement, upon which payment to said 
seller by said buyer is to be based, 

funds transfer request means for requesting a 
20 transfer of funds based on a detailed payment 
statement made according to said detailed payment 
statement making means, and 

notification means for notifying said witness of 
a transfer of funds, when funds are transferred to 
25 said seller based on a funds transfer request 
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according to said funds transfer request means. 

8. An account settlement system using a witness 
system according to claim 7, wherein 

5 said detailed payment statement is made in 

accordance with payment terms. 

9 . An account settlement system using a witness 
system according to claim 8, wherein 

10 said payment terms are managed by said witness. 

10. An account settlement system using a witness 
system according to claim 7, wherein 

said seller checks said detailed payment statement 
15 against documents stored in memory according to said 
memory means. 

11. An account settlement system utilizing a witness 
system according to claim 7, wherein 

20 making of said detailed payment statement is 

undertaken by said buyer. 

12. An account settlement system utilizing a witness 
system according to claim 7, wherein 

25 making of said detailed payment statement is 
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undertaken by said witness. 

13 . An account settlement system utilizing a witness 
system according to claim 12, wherein 

5 said buyer checks said detailed payment statement 

in accordance with documents stored in memory 
according to said memory means. 

14. An account settlement system utilizing the 
10 witness system according to claim 7, wherein 

when said witness system notarizes notarization 
documents, notification of said notarization is given 
to both the buyer and seller. 

15 15. An account settlement system utilizing a witness 
system, comprising 

notarization document making means for making 
notarization documents for each said seller record 
based on seller records sent from the seller, 

20 sending means for sending to a notarization 

authority documents made according to said 
notarization document making means, and for sending 
said documents from said notarization authority to 
said buyer, 

25 confirmation means for confirmation by said buyer 
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as to whether the contents of said buyer record are 
in agreement with the contents of said documents sent 
according to said sending means, 

a witness to certify that said documents are 
5 accurate, when said substantive agreement is confirmed 
according to said confirmation means, 

memory means for storing in memory documents 
notarized by said witness, 

detailed payment statement making means for making 
10 by said buyer, with reference to said documents stored 
in memory according to said memory means, a detailed 
payment statement upon which payment by the buyer to 
the seller is based. 

request means for requesting a financial 
15 institution to issue a check to said buyer, based on 
a detailed payment statement made according to said 
detailed payment statement making means. 

16. An account settlement system utilizing the 
20 witness system according to claim 15, wherein 

said financial institution notifies said witness 
when a check is issued based on said check issue 
request . 

25 17. An account settlement system utilizing a witness 
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system, comprising 

notarization document making means for making 
notarization documents for said each seller record, 
based on seller records sent from the seller, 
5 sending means for sending to a notarization 

authority documents made according to said 
notarization document making means, and for sending 
said documents from said notarization authority to the 
seller, 

10 confirmation means for the seller to confirm 

whether the contents of said seller record are in 
agreement with the contents of said documents sent 
according to said sending means, 

a witness to certify that said documents are 

15 correct, when substantive agreement between said 
documents and seller record is confirmed according to 
said confirmation means, 

memory means for storing in memory documents 
notarized by said witness, 

20 detailed payment statement making means for 

making, with reference to said documents stored in 
memory according to said memory means, a detailed 
payment statement upon which is based payment by said 
buyer to said seller, and 

25 request means for requesting a financial 
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institution to issue a note to said buyer. 

18. An account settlement system utilizing a witness 
system according to claim 17, wherein 

5 said witness is notified when said financial 

institution has issued a note based on said note 
issuance request. 

19 . An account settlement system according to claim 
10 7, wherein 

at the time said detailed payment statement is 
made, set-off processing is performed when said buyer 
is possessed of a receivable against said seller. 

15 20. A witness system according to claim 1, wherein 
said witness confirms in advance a buyer and a 
seller and utilizes an authentication certificate when 
performing any procedure. 

20 , 21 . An account settlement system utilizing said 
witness system according to claim 7, wherein 

said witness confirms in advance a buyer and a 
seller and utilizes an authentication certificate when 
performing any procedure. 

25 
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22. A witness system according to claim 1, wherein 
data transmitted among said witness, buyer, and 

seller, are encoded. 

23. An account settlement system utilizing said 
witness system according to claim 7, wherein 

data transmitted among said witness, buyer, and 
seller, are encoded. 

24. A witness system according to claim 20, wherein 
said witness notarizes said transmitted data. 

25. A method for document confirmation by a witness 
S3fstem, comprising 

a confirmatory document making process for making 
confirmatory documents for said each seller record, 
based on a seller record sent from a seller, 

a sending process for sending to a witness 
documents made according to said confirmatory 
document, and for sending said documents from said 
witness to said seller, 

a confirmation process whereby said seller 
confirms whether the contents of said seller record 
are in agreement with the contents of said documents 
sent according to said sending process, 
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a notification process whereby a witness, when 
confirming substantive agreement according to said 
confirmation process, confirms that said documents are 
accurate and notifies said buyer and said seller of 
5 said confirmation, and 

a memory process whereby said confirmed documents 
are stored in memory. 

26. An account settlement method utilizing a witness 
10 system, comprising 

a notarization document making process to make 
notarization documents for said each seller record, 
based on a seller record sent from a seller, 

a sending process to send to a notarization 
15 authority documents made according to said 
notarization document making process, 

a confirmation process whereby said seller 
confirms whether the contents of said seller record 
are in agreement with the contents of said documents 
20 sent according to said sending process, 

a notification process whereby a witness notarizes 
that said documents are accurate and notifies said 
buyer and said seller of said notarization, when said 
substantive agreement is confirmed according to said 
25 confirmation process, 
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a memory process for storing in memory said 
notarized documents, 

a detailed payment making process for making, with 
reference to said notarization documents stored in 
5 memory according to said memory process, a detailed 
payment statement upon which is based payment by said 
buyer to said seller, and 

a funds transfer request process for requesting 
the transfer of funds to said seller, based on a 
10 detailed payment statement made according to said 
detailed payment statement making process. 

27. A computer-readable memory medium containing a 
program causing a computer to execute the document 
15 confirmation processes performed by a witness system, 
comprising 

a confirmatory document making process to make for 
each said seller record a confirmatory document, based 
on a seller record sent from a seller, 
20 a sending process to send to a witness documents 

made according to said confirmatory document making 
process, and for sending said documents to said buyer 
and said seller, 

a confirmation process whereby said seller 
25 confirms whether the contents of said seller record 
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are in agreement with contents of said documents sent 
according to said sending process, 

a notification process whereby a witness confirms 
that said documents are accurate and notifies said 
buyer and said seller of said confirmation, when said 
substantive agreement is confirmed according to said 
confirmation process, and 

a memory process for storing in memory said 
confirmed documents. 

28 . A computer-readable memory medium containing a 
program to cause a computer to execute an account 
settlement process using a witness system, comprising 

a notarization document making process for making 
for said each seller record a notarization document, 
based on a seller record sent from a seller, 

a sending process for sending to a notarization 
authority documents made according to said 
notarization document making process, and for sending 
said documents from said notarization authority to 
said seller, 

a confirmation process whereby said seller 
confirms whether the contents of said seller record 
and the contents of said documents sent according to 
said sending process are in agreement, 
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a notification process whereby a witness notarizes 
the fact that said documents are accurate and notifies 
said buyer and said seller of said notification, when 
said substantive agreement is confirmed according to 
5 said confirmation process, 

a memory process for storing in memory said 
notarized documents, 

a detailed payment statement making process for 
making, with reference to said notarization documents 
10 stored in a memory according to said memory process, 
a detailed payment statement upon which is based 
payment by said buyer to said seller, and 

a funds transfer request process for requesting 
that funds be transferred to said seller, based on a 
15 detailed payment statement made according to said 
detailed payment statement making process. 

29. A witness system, comprising 

first computing means for making document data, 
20 second computing means for confirming the contents 

of said document data, and 

third computing means for storing in memory said 
confirmed document data, or for performing 
notarization of said document data. 



25 
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30. A witness system according to claim 29, wherein 
said storing in a memory and substantive 

confirmation of document data are executed according 
to a screen display of said calculating means. 

5 

31. A witness system according to claim 29, wherein 
said document data comprise at least one of either 

a written will, written contract, written application, 
px~ivate communication, written report, or written 
10 summons, or a combination thereof. 

32. A witness system according to claim 29, wherein 
said first computing means encodes the said 

document data, transmits said data to said second 
15 computing means through said third computing means, 
confirms the contents of and further encodes said 
data, sends said data to said third computing means, 
and 

said third computing means further encodes the 
20 data sent from said second computing means and sends 
said data to said first or second computing means, or 
both. 

25 33. A witness system according to claim 32, wherein 
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with respect to data transmitted among said first, 
second, and third computing means, a public access key 
for the sending side is sent in advance to the 
receiving side, and a receiving side public access key 
5 is sent to the transmitting side, 

a message, obtained by combining 

(a) a message encoded with a sender secrecy 
key and further encoded by DES 
and 

10 (b) DES-decoding DEK, encoded with a 

receiver's public access key, is transmitted as 
transmission data, and, at said receiving side, said 
transmission data is received, DEK produced therefrom 
by decoding said data with a secrecy key corresponding 

15 to said public access key, 

data encoded with DES is encoded with DEK, and 
data decoded by said sender- side secrecy key is 
compounded by means of said sender side public access 
key. 

20 

34. An account settlement system, comprising 

payment request means for making a detailed 
statement of a payment object and for sending a 
payment request, and 
25 comparison means for comparing a detailed payment 
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statement transmitted according to said payment 
request means with a seller-side sales record. 



Abstract of the Disclosure 



The present invention relates to a witness system 
that takes advantage of EDI (electronic data exchange) 
5 to perform efficient distribution and account 
settlement (accounting) processes between selling and 
buying companies. The present invention also provides 
a system ensuring information safety and offers 
account settlement (accounting) processes utilizing 
10 said witness system. A buying company's computer 5 
makes documents according, illustratively, to delivery 
vouchers or order vouchers, and sends said documents 
to a selling company's computer 6 via a notarization 
authority 7. The selling company compares 

15 authentication documents so transmitted with, 
illustratively, delivery vouchers or order vouchers 
that the selling company itself has issued, and, after 
checking for substantive errors and determining that 
the contents of said documents are correct, executes 
20 a confirmation response with respect to the 
notarization authority. The notarization authority 
registers said documents in the witness server's 8 
receipts detail table 20 and notifies buying company 
and selling company that the notarization authority 
25 has authenticated (said documents). This structure 
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makes possible the making of accurate detailed payment 
statements when, for example, a detailed payment 
statement is made or a funds transfer is executed 
based on confirmed data. Furthermore, the checking 
of said detailed payment statement by a buying company 
and a selling company is made simpler through 
reference to the above-described witness system server 
8.. 
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I believe I am the original, first and sole inventor (if only one name 
is listed be/ow) or an original, first and joint inventor (if p(ura( 
names are listed below) of the subject matter which is claimed and 
for which a patent is sought on the invention entitled 

WITNESS SYSTEM 



the specification of which is attached hereto u< 
box is checked: 



it. 



n was filed o 



as United States Application Number or 
PCT International Application Number 



I hereby state that I have reviewed and understand the a 
the above identified specification, including the claims, as 
amended by any amendment referred to above. 



fLU. S-^tSlWiS^sS 3 7 fS'S 1 3» 5 6 *H(C3SjEc.n.2i £ I acknowledge the duly to disclose information which is material to 
H*}. ^3rSlS«flSf:^: , .'T£3?^fS4!-i4'^f:i"<;«y;i I patentability as defined in Title 37. Code ofFederal Regulations. 



Under the Paperwork Reduction A 
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Japanese Language Declaration 



mt. x&m&kX 3 5 *a 1 1 9^ (a)-(d> /«:zi±3 ss* 

(b) #Kat-£-T3£<o. X WVX}Y<r>&<r>'yU < t {>— *p3«rrff 
te\.T^Z&&t&f)4ktt 3 6 5 (aJtfKS^WiSiiiK. x 

Tic ^^-?ts;it-. tLtvtt. 

Prior Foreign Application^) 

9U4Va>9£ffUM 

1 0-1 21 295 



Japan 



(Number) 
<S^> 



(Country) 



(Number) 



(Country) 



«.t. S5 3Sfc.*Sf£&l 1 9&(e)«<Cg^-CT3c«* 



(Application No.) 



(Filing Date) 



fc. *HiJB«)«-»*Ee«>rtfic* 1 *iaifeft3B3 5 & 1 1 2^ 



(Application No.) 

(muss*?) 



(Application No.) 

(H«"S=*> 



(Filing Date) 



(Filing Date) 
(SIM B) 



1 8 MS I 0 (J l^lc.STS'. !HfcSfcj;tfiI#. t»L<ti* 
f£<a«F«l*rf/j:x}i-. }ft«aufc. XSiSr-Kft-rSKfeteiT 



I hereby claim foreign priority under Title 35, United States Code. 
Section 119 (a|-<d) or 365(b) of any foreign applications) for patent 
or inventor's certificate, or 365(a) of any PCT International 
apptication which designated at least one country other than the 
United States, listed below and have also identified below, by 
checking the box, any foreign application for patent or Inventor's 
certificate, or PCT International application having a filing date 
before that of the application on which priority is claimed. 

Priority Not Claimed 

"3 0 -Hi / Adt~ i 1 / 1 9 9 8 Q 

{Day/Month/Year Filed) 



(Day/Month/Year Filed) 
(ffSlMPJia) 



I hereby ctaim the benefit under Title 35. United States Code, 
Section 119(e) of any United States provisional applications) fisted 
below. 



(Application No.) 



(Filing Date) 
(fHJSB) 



I hereby claim the benefit under Title 35. United States Code. 
Section 120 of any United States applications), or 365(c) of any 
PCT International application designating the United States, listed 
below and. insofar as the subject matter of each of the claims of 
this application is not disclosed in the prior United States or PCT 
International application in the manner provided by the first 
paragraph of Title 35. United States Code Section 112. I 
acknowledge the duty to disclose information which is material to 
patentability as defined in Title 37. Code of Federal Regulations. 
Section 1.56 which became available between the filing date of the 
prior application and the national or PCT International filing date of 
application. 

(Status: Patented. Pending, Abandoned) 
(Status: Patented. Pending. Abandoned) 

(3izs? : wjfffisr. «k*. nmm 

I hereby declare that all statements made herein of my own 
knowledge are true and that all statements made on information 
and belief are believed to be true: and further that these 
statements were made with the knowledge that willful false 
statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the 
United States Code and that such willful false statements may 
jeopardize the validity of the application or any patent issued 
thereon. 
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Japanese Language Declaration 
(R^SrKMS) 

«W fV.ZTXKn&W&tLr. *Mt&>CKl-l-Z> — ^JfJ POWER OF ATTORNEY: As a named inventor. I hereby appoint 
r.W#«#«fc::ttL-CiSff-}-0#ISX-iL fcllftSA the following attomey(s) and/or agent(s) to prosecute this 
I,, -<:jpf}#t'f%g,1 l *?zL'£~i'. ' (#Sx\ application and transact all business in the Patent and Trademark 

X « * £ £ t/Sfc R SMl" teWZilO) - t) Office connected therewith (Jtsf name and registration number) 

. _ .... d: . . 9C 908" John C. Garvey, 28.607; J. Randall Beckers, 



«Si£fT3fc 
H J. Staas 
Staas & Halsoy 

700 Eleventh Street, N.W. Suite 500. 
Washinfjton, DC 20OO1 



Send Correspondence to: 
H. J. Staas 
Staas & Halsey 

700 Havanth Street, N.W. Suite 500 
Washington, DC 20001 



Telephon 



: 202-434-1500 
202-434-1501 



Direct Telephone Calls to: (name and telephone number) 



Telephone: 202-434-1500 
Facsimile: 202-434-1501 





Full name of sole or first inventor 

Hajime KOJIMA 




Oc£*26, 1998 


f+:Sf 


Residence*' x " 

Kanagawa, Japan 




Citizenship 

Japan 




Post Office Address c/o FUJITSU LIMITED, 
1-1, Kamikodanaka 4-chome, 


Nakahara-ku f Kawasaki-shi, 
^n anawa ?1 1-8588. Jar>an 




FuB name ol second joint inventor, if any 

Toshihiko KAJI 








Residence - ' - 

-Kanagawa, -lagan , 


us 


Citizenship 

Japan 




Post Office Address c/o FUJITSU LIMITED, 

1-1. Kamikodanaka 4-chome, 


■ ~~ Nakahara-ku, Kawasak±-siix , 

Kanaaawa 211-8588, Japan 



iKHjatttOfcHTSfflfrKo-. .-C «,(?«KJeaL . *&5rt (Supply similar information and signature for third and subsequent 
- . v , joint inventors.) 







Full name of third joint inventor, if any 

Yasuharu ITO 








Third inventor's signature Date 

vwr oct - 26 > 


1998 


ft m 




Reside^nce 

Kanagawa, Japan 




m m 




Citizenship 

Japan 








P„ct ntfi, 0 »^ fltc c/o FUJITSU LIMITED 
Post Office Address ' 
1-1, Kamikodanaka 4-chome, Nakahara- 






ku, Kawasaki- shi, Kanagawa 211-8 
Japan 


588 






Full name of fourth joint inventor, if any 








Fourth inventor's signature Date 




a m 




Residence 




a if 




Ci tizenship 








Post Office Address 












Full name of fifth joint inventor. if any 






Bff 


Fifth inventor's signature Date 




ft Eff 




Residence 




H If Citizenship 






Post Office Address 










Full name of sixth joint inventor, if any 






Btt 


Sixth inventor's signature Date 




ft fifi 




Residence 




H » 




Citizenship 








Post Office Address 








5Ci) 


(Supply similar information and signature 
seventh and subsequent joint inventors.) 


for 



